VRT processed dataset: unscale source raster values #11623
Conversation
indeed. I thought you were going to silently add the unscale processing functions as a first step. Wouldn't that simplify things ?
or just use the dataset returned by GDALTranslate("", hSrcDS, options = "-f VRT -unscale") which will handle all details, including reading from overviews. |
In some ways. But there's still a problem where the
I'll give this a try. |
|
macos_build failure unrelated, and should be solved by rebasing on top of latest master |
dbaston
force-pushed
the
processed-vrt-unscale-2
branch
from
2048e21 to
d514839
Compare
|
@dbaston Please also edit frmts/vrt/data/gdalvrt.xsd to add the new attribute |
Alternative to #11573 . Introduces an attribute
scaleto<Input>with default valueauto. This will cause input datasets with a defined scale or offset to be unscaled to Float64 (also causing output bands to be Float64).<Input unscale="false">prevents this and keeps the current behavior.<Input scale="true">invokes the unscaling machinery regardless of the defined scale/offset values in the input dataset, so that the output type is always consistent.I don't love the implementation which ends up touchingVRTProcessedDatasetin several places. I think a cleaner implementation could involve creating a method likeGDALRasterBand* GDALRasterBand::GetUnscaled(). If the band was not scaled it could return a reference to itself; for a band with scaling it could return a a wrapperGDALScaledRasterBandwith appropriate overloads ofIRasterIO,GetNoDataValue, etc. This would also provide a consolidated location for an optimized (SSE?) implementation of the unscaling.cc @jratike80